Network servers are becoming increasingly important to large enterprises to manage networks, host data, and otherwise execute a wide variety of networking tasks. As such, large enterprises may have hundreds, if not thousands, of blade servers mounted in racks to support these networking tasks. In fact, large enterprises may have rooms dedicated to housing racks of blade servers in buildings strewn throughout a country or even the world.
When one of these blade servers malfunctions a network operator can often determine an internet protocol (“IP”) address or media access control (“MAC”) address of the malfunctioning or non-responsive blade server. If the problem can be solved remotely over a network, the network operator can fix the blade server without physically locating it. If the problem is such that the blade server must be physically manhandled to remedy the malfunction, the problematic blade server must be located.
However, correlating an IP address or MAC address to the physical blade server can be a problem in and of itself. In fact, in large enterprise settings where entire rooms or even buildings are dedicated to housing racks of blade servers, finding the physical location of a blade server can be like finding the proverbial needle in a haystack. Even once the rack containing the malfunctioning blade server has been tracked down, locating the particular blade server within the rack can present yet another problem.
Modern racks can house more than 70 individual blade servers per rack in a dense, compact form factor. If a technician is lucky, the malfunctioning blade server “may” have a blinking light or other form of visual indicators. However, such visual indicators may not be present, not triggered by the particular malfunction, or even malfunctioning themselves. Thus, locating the physical location of a malfunctioning or even non-malfunctioning blade server can be a task in and of itself, a waste of time and resources, and simply a headache for the individual on whom the task is bestowed.